The Role of Proof in a Formal Specification of the Speedway Rulebook

Whilst some undergraduate introductions to formal methods play down the role of proof, others have tended to emphasize it as the true payback of using formal methods in the first place. This paper describes how a sports application can be used to illustrate many of these paybacks in a readily understandable way. It illustrates the difficulty of arriving at a formal specification of a complex specification, which is often a collaborative effort between at least two parties, and how this affects the chosen development method. The maintenance of specifications is also considered, in the light of frequent and complex rule changes, in some cases, as a result of "case law" during mid-season. 1 Proof in Formal Methods Many undergraduates are introduced to formal specification, yet learn little or nothing of proof. The emphasis is on the fact that the formal notation provides a precise and unambiguous specification, unlike a natural language specification, or the original requirements document. Formalizing the specification can help the developer firm out their ideas, resolve ambiguities, and, if suitably translated, provide a basis for discussion and negotiation with the client. These are laudable benefits and undergraduates are expected to practice developing formal specifications in Z, or VDM, or some other notation. Proof, on the other hand, is rarely covered in such depth, if at all. This may be partly because it is difficult, especially as tool support is limited [6]. In teaching VDM to undergraduates on vocational courses, however, the first author has actually emphasized, rather than played down, the role of proof. The undergraduates in question had all worked on industrial placement for a year before taking my modules, many of them in the banking and insurance sector, or for local authorities. If they had any opinion on formal methods at all, it was that they were never used − they were not "for real". Teachers trying to overcome this view find much resistance, as some students find it a very convenient one to hold for a subject which is inherently difficult for many of them, especially if their mathematical knowledge is sketchy. The strategy employed was as follows: 1. Revise the basics needed alongside learning VDM notation 2. Do plenty of examples from familiar domains 3. Let them make mistakes. It is particularly easy to forget vital preconditions, for example. 4. Use proof to help detect these mistakes. The third point is the launching point for motivating formal methods. One thing the students do understand from their experience, both academic and industrial, is that people make mistakes. They make mistakes in requirements documents, in informal specifications, in programming, in testing, and in debugging. Mistakes can be embarrassing if undetected and should be uncovered at all costs. Of course, now that they are learning VDM, they make mistakes in that too − so far, just another notation, like a program language, only perhaps without the benefits of being executable and therefore testable. If they can be persuaded that proof will help them discover the errors at an early stage, all that is left for the teacher to do is to convince them that there is then a path from specification to program. Whereas students can follow textbook examples, such as those given in [8] or [3], and the preconditions seem "obvious", as soon as they start doing examples, they do make mistakes. This is especially true in a tutorial situation, where they are asked to do examples on the board. A common feature of the resulting attempted proof is that part of the right hand side is completely underivable, when students will say things like "Oh, but of course, we have to make sure that the number of seats is less than capacity before we accept the airline booking" − and realize that there is a missing precondition. The Role of Proof in a Formal Specification of the Speedway Rulebook Irish Workshop on Formal Methods, 1999 2 2 A pedagogic example Students will know that one source of errors is the user, and that validation routines form an important role. An entertaining example, due to Yves Ledru can be found in the VDM examples repository. This example was used at the Diplôme d'Etudes Superieures Spécialisées Engéenie Informatique at the Université Joseph Fourier, and illustrates many issues, including how VDM may be used for a sporting example, user error and detection. It also contrasts two approaches to writing VDM specifications. The example models the part of the referee's rulebook in force during the 1994 World Cup, which stipulates (amongst other things) that no more than one substitute goalkeeper, and two substitute outfield players, may be made during the course of a match. This rule was violated during the Italy-Norway game, when the Italian goalkeeper was sent off. An outfield player was immediately substituted for the substitute goalkeeper, but later on two further outfield substitutions were made. Although it is true to say that this was illegal, this is rather nit-picking, since if the first outfield player had been "designated as the goalkeeper" just before being substituted, no breach would have resulted from the subsequent actions. We mentioned earlier that we need to show students how to find a path from specification to code. Ledru sketches two alternative approaches. The first approach used the KIDS/VDM environment [4,5] including semiautomatic program synthesis [7]. The initial specification is in an implicit style. The program synthesized is written in REFINE, an ML-like functional language. This program is then run on the actions performed during the match: namely, the sending-off, and the three substitutions. The program is run with and without an outfield player being designated as the goalkeeper. However, the program specified is very simple, and does not contain any validation routines. As the result, the program does no checking of user input, and the user is left to discover the mistake by examining the state after each execution. The second approach uses the IFAD toolbox [2]. This tool support for writing VDM specifications is proving very popular, but, as yet, the commercially available version does not support proof. Users are therefore encouraged to use its very sophisticated testing support instead. However, this involves the user in writing an executable specification. In the simple example above, this meant only minor changes, for example Implicit style Explicit style RED-CARD(p : player) RED-CARD : player → ( ) ext wr on-field-players : player-set RED-CARD(p) ∆ wr potential-substitutes: player-set on-field-players : = on-field-players \ {p}; pre p ∈ on-field-players ∨ potential-substitutes: = potential-substitutes \ {p} p ∈ potential-substitutes pre p ∈ on-field-players ∨ p ∈ potential-substitutes post } { \ _ _ } { \ _ _ _ _ p s substitute otential p s substitute potential p players field n o players field on + +